The need for getting products to market faster, better and cheaper is growing as product life cycles are shortening, especially in the area of high technology and consumer goods. As such, the need to consider all of the aspects of developing a product, from idea generation through production, and post production product support (and even disposal) is critical. Recent studies and research document that there is a great need for the planning and integration of the various aspects of product production, and that technology to accomplish this integration is absent despite the explosion of database and information storage devices and methods. “PDMA Research on New Product Development Practices: Updating Trends and Benchmarking Best Practices” by Abbie Griffin, J PROD INNOV MANAG 1997: 14:429–458, “Defining Next-Generation—How Leading high-tech Companies Develop New Products”, Harvard Business Review, November-December 1997, pg. 116–124, and “PDM's Productivity Payback”, by Paula M. Noaker, Integrated Design and Manufacturing November/December, 1997.
A typewriter can't show you how to write a book. Similarly scheduling tools such as Microsoft Project or Project Office can't show the user how to plan and integrate the process of product development. User's Guide for Microsoft Project 98, Microsoft Press, Redmond, Washington, 1984–1997. Because these types of scheduling tools typically comprise functional shells with little or no content, they rely on the planning management expertise of the user to conceptualize and integrate the planning and process steps for product development and then budget resources as separate events. The user then memorializes the steps for product development derived from personal expertise by manually entering the planning and process steps along with the allocated resources into the scheduling tool. As such, companies may generate ad hoc approaches to product development that are dependent upon people doing their “best” planning management, which can fail to identify, or tie various process activities or methodologies, and which can fail to provide coherent information transfer throughout the organization.
Because there is a large commercial market for scheduling tools, the manner of providing functional scheduling shells has taken a variety of forms. In spite of the variety of scheduling tools available to the consumer, substantial problems remain unresolved with respect to providing a planning management device which assures repeatably successful integrated product development.
A significant problem with existing scheduling tools is that they are not planning systems. A schedule may be nothing more than a calendar with resources allocated over time. A plan by comparison defines activities to be performed over time, what is deliverable from the activity, and integrates the deliverables with subsequent defined activities. As mentioned above, scheduling tools typically comprise functional shells with little or no content, a plan provides the content. Sophisticated scheduling tools, such as Project Office may integrate and update many individual schedules such as those prepared using Microsoft Project but these tools do not provide a planning system.
A significant problem with existing scheduling tools is they assume that the user knows how to plan and manage a project. This assumption of subject matter expertise which may not exist with respect to coordinating the various aspects of product development may result in a failure of proper requirements identification. Often, rather than identifying the overall organizational requirements for development of a product, users with limited planning management expertise tend to target various solutions in technology and process to isolated problems in the organization. Providing solutions to problems that have narrow focus, however, may fail in the first instance to properly identify all the requirements for product development, and in the second instance may fail to integrate the efforts of the entire organization.
A related problem with existing scheduling tools is that they place the burden of being a lexicographer on the user. However, consistent use of terminology rarely cuts across an entire organization and miscommunication may occur as individuals attempt to interpret terminology within the context of their own specialty area. Moreover, allocation of resources by a user having little subject matter expertise in a specialty may result in incorrect budget allocations based upon incorrect perceptions of the activities performed in particular product development step. Likewise, individuals with varying subject matter expertise may incorrectly draw upon budgeted resources for product development steps when product development steps are defined by generic indicators. Ultimately due to these miscommunications, the scheduling tool may, in-part or in its entirety, lose its usefulness as a baseline for integrating product development events and as tool for comparing the budgeted resources to the real time use of resources.
Another problem with existing scheduling tools is that they may only have a single level of review of product development content or resource estimation or resource allocation. Because the product development content and resource lists remain outside of the project scheduling tool the project scheduling tool may not allow multiple users to use the project scheduling tool as a forum for interactive review and comparison.
Another problem with existing scheduling tools or spreadsheets may be that they provide few metrics for comparing success or failure within the project or across projects. Typically, scheduling tools may compare resource expenditure with the a resources baseline. The reasons for the occurrence of variation from the baseline may remain unknown. This may result from the inability to memorialize various aspects of real time experiences in the product or service production cycle for later review.
Another problem with existing scheduling tools may be that they do not allow for construction of consistent baseline project development plans. Because project planning expertise, subject matter expertise and planning techniques may vary among individuals within an organization, and because project planning may be performed as isolated steps by various members of the organization which may be subsequently integrated by entering the planning details into a project scheduling system, the baselines for the same product in different production cycles or similar products in the same production cycle may have substantial variation.
Another problem with existing scheduling tools may be a lack of product development content. Typically product scheduling tools are functional shells into which the content from separate project planning steps may be added. These types of tools do not provide the user with interactive subject matter expertise about the product being developed, about resources to perform activities, or about the activities themselves. The scheduling tool may not link the details of such content into useful packets of information for the user, or show the user how to create dependency between various aspects of the content. Typically, project scheduling tools calendar resources which are manually input to fields by the project planning user. However, the project scheduling tool or spread sheet formats may not show the user how to plan a project resulting in resources to be entered into these databases external from the project planning.
A related problem may be that existing scheduling tools may not allow product development content to be entered into the functional shell of the project scheduling tool. The functional shell may as a result have little or no product development content to guide the project scheduling user as to how to use calendered resources.
Another problem may be that existing scheduling tools do not provide guidance in assigning dependencies between product development content. Dependencies between product development content are typically determined outside of the project scheduling tool. The project scheduling tool user then enters the dependencies manually into fields within the project scheduling tool.
Another problem may be that existing project scheduling tools may not be loaded with sufficient product development content automatically. A description of resources may be calendered with existing project scheduling tools but links to additional information may not be established.
Another problem may be that product development content which may be loaded automatically to existing project scheduling tools may not automatically load the assigned dependencies between product development content. The dependencies may have to be assigned manually between product development content within the existing project scheduling tools.
Still another problem with existing scheduling tools may be that they are too cumbersome. With respect to some scheduling tools, the number of features, the use of the features, and coming to an understanding of the relationship of the features to one another results in an extended learning period for the user. Over this learning period the user may have various levels of success in correctly and efficiently scheduling task activities.
A related problem is that existing scheduling tools are too labor or time intensive. One aspect of this is previously discussed extended learning curve. A second aspect is that the user must either have or obtain an expertise in project or planning management so that the scheduling tool can be used properly. A third aspect of this problem may be that the user must acquire multi-discipline subject matter expertise before identification, integration and coordination of product development steps may occur. Gaining subject matter expertise requires the expenditure of time to allow sufficient interaction with other persons or through academic achievement.
Another related problem is that the process of both learning to use feature rich scheduling tools, acquiring multiple-discipline subject matter expertise, and obtaining project or planning management expertise is too complicated. This is especially true when getting products to market faster, better and cheaper may be a priority or where the product life cycles may be short.
As to each of these problems of integrated product development, the present invention discloses technology which addresses every one of these problems in a practical fashion.